DerivedProjectedCRS: deal with lack of explicit CS in BASEPROJCRS in WKT #4124
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…EPROJCRS Current WKT2 grammar doesn't allow an explicit CS (Coordinate System) in the BASEPROJCRS of a DERIVEDPROJCRS. This leads to ambiguities when instanciating the BASEPROJCRS. Cf OSGeo/gdal#9732 (comment) for a longer analysis When importing such a DerivedProjectedCRS, we apply the following strategy to try to reconstrut the CS of the baseProjCRS: - if the baseProjCRS has an ID[], do a datebase lookup for this object, and if found, use its CS - otherwise, do a database lookup from the name of the baseProjCRS, and if found, use its CS - otherwise, browse through the PARAMETERs of the CONVERSION of the BASEPROJCRS, and if there is at least one such PARAMETER that has a linear unit, and if all PARAMETERs with a linear unit have the same one, then use it to reconstruct a Easting/Northing CartesianCS. - otherwise, fallback to current behaviour, that is return a Easting/Northing CartesianCS with metre unit. Fixes OSGeo/gdal#9732
Current WKT grammar (as of WKT2 18-010r11) does not allow a BASEPROJCRS.CS node, but there are situations where this is ambiguous and we want to allow one. Cf OSGeo/gdal#9732 (comment)
…ns where there's ambiguity Cf OSGeo/gdal#9732 (comment)
rouault
added a commit
to rouault/gdal
that referenced
this pull request
Apr 23, 2024
We export CRS objects to PROJJSON rather than WKT2:2019 because PROJJSON is a bit more verbose, which helps in situations like OSGeo#9732 / OSGeo/PROJ#4124 where we want to export a DerivedProjectedCRS whose base ProjectedCRS has non-metre axis. Fixes OSGeo#9732
rouault
added a commit
to rouault/gdal
that referenced
this pull request
Apr 23, 2024
We export CRS objects to PROJJSON rather than WKT2:2019 because PROJJSON is a bit more verbose, which helps in situations like OSGeo#9732 / OSGeo/PROJ#4124 where we want to export a DerivedProjectedCRS whose base ProjectedCRS has non-metre axis. Fixes OSGeo#9732
rouault
added a commit
to rouault/gdal
that referenced
this pull request
Apr 23, 2024
We export CRS objects to PROJJSON rather than WKT2:2019 because PROJJSON is a bit more verbose, which helps in situations like OSGeo#9732 / OSGeo/PROJ#4124 where we want to export a DerivedProjectedCRS whose base ProjectedCRS has non-metre axis. Fixes OSGeo#9732
rouault
added a commit
to OSGeo/gdal
that referenced
this pull request
Apr 24, 2024
We export CRS objects to PROJJSON rather than WKT2:2019 because PROJJSON is a bit more verbose, which helps in situations like #9732 / OSGeo/PROJ#4124 where we want to export a DerivedProjectedCRS whose base ProjectedCRS has non-metre axis. Fixes #9732
|
The discussion with the OGC CRS SWG about this issue are unconclusive for now, so let's merge this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DerivedProjectedCRS WKT import: workaround lack of explicit CS in BASEPROJCRS
Current WKT2 grammar doesn't allow an explicit CS (Coordinate System) in the BASEPROJCRS of
a DERIVEDPROJCRS. This leads to ambiguities when instanciating the
BASEPROJCRS. Cf Incorrect unit conversion on affine transformation gdal#9732 (comment)
for a longer analysis
When importing such a DerivedProjectedCRS, we apply the following
strategy to try to reconstruct the CS of the baseProjCRS (if not present.
cf later bullet point where we mention adding it on export side):
and if found, use its CS
if found, use its CS
BASEPROJCRS, and if there is at least one such PARAMETER that has a
linear unit, and if all PARAMETERs with a linear unit have the same
one, then use it to reconstruct a Easting/Northing CartesianCS.
Easting/Northing CartesianCS with metre unit.
Fixes Incorrect unit conversion on affine transformation gdal#9732
WKT2 grammar: allow a DERIVEDPROJCRS.BASEPROJCRS.CS node
DerivedProjetedCRS WKT export: emit a BASEPROJCRS.CS node in situations where there's ambiguity